Method and apparatus for delivering services in a constrained environment

ABSTRACT

A system and method for distributing services to a handheld device in a constrained networking environment is disclosed. A service provider ( 102 ) creates an advertisement containing information about a service. The advertisement is sent to emitter ( 108 ). Emitter ( 108 ) transmits the advertisement to a wireless client ( 112 ) using a wireless optical signal ( 142 ). Client ( 112 ) receives optical signal ( 142 ) if it is located within a coverage area associated with emitter ( 108 ). The advertisement is displayed on client ( 112 ) if a user of client ( 112 ) has previously expressed an interest in the service.

BACKGROUND OF THE INVENTION

[0001] 1. Field of the Invention

[0002] The present invention relates generally to the field of wirelessdata communications and more particularly to delivering services towireless devices in a constrained network environment.

[0003] 2. Description of Prior Art

[0004] Proliferation of the Internet has made it possible for users toaccess vast amounts of data almost effortlessly. For example, with onlya few mouse clicks users may inundate themselves with data such as;commercial data, scientific data, educational data, financial data, anddata on general areas of interest such as sports and hobbies. Ease ofaccess to networked data has helped fuel demand for even more types ofdata. Accompanying users' demand for data is a desire to have datasorted based on user preferences before the data is viewed or utilized.Failure to deliver data to users in a sorted manner wastes the users'time, leads to network congestion because of repeated requests for newdata, and wastes processing and storage resources if large amounts ofdata must be processed to present a user with relevant information.

[0005] Problems associated with unfiltered data are especiallychallenging when users wish to take advantage of information whileremaining mobile. These users are increasingly relying on wirelessdevices such as personal digital assistants (PDAs), handheld computersand web enabled cell phones for processing information when on the go.One example would be a wireless device used to store personal contactinformation, calendars, email, business information, and financialinformation. While wireless devices have some processing capabilities,they are very limited when compared to desktop computing devices. Sincewireless devices normally run on batteries, efforts must be made toreduce power consumption. Typically, slow speed processors and reducedmemory sizes are employed to reduce power consumption. In addition,reducing the use of, or eliminating, power hungry add-on components suchas radio frequency transceivers (e.g. cellular and wireless Ethernet),modems, global positioning system (GPS) receivers, and the like help toextend the life of batteries in wireless devices.

[0006] Context sensitive computing may be employed to address some ofthe shortcomings associated with providing unfiltered data to wirelessdevices. More specifically, context sensitive computing attempts to sendusers only data that is relevant to their needs. Context as used hereinis comprised of two parts. The first part is environmental context andit describes the physical location of a user, e.g. an airport, a car, ora store. The second part is referred to personal context and it isassociated with a user's personal preferences, e.g. a particular coloredshirt, a favorite author, etc. In principle, context sensitive computingmakes it possible to provide users of wireless devices having limitedprocessing capabilities with relevant information.

[0007] To aid in the understanding of how contextual computing can aidusers of wireless devices by providing them with relevant information,an example will be presented. In this example a consumer wants to make apurchase at a shopping mall. In addition, the consumer wants to haverelevant information, such as the latest sale price and industry reviewsfor a desired product, and the consumer wants to know which merchantcarries a particular style or colored item. The consumer has two primaryoptions for using data to facilitate selection of a product and apossible purchase. For example, the consumer may first review data intheir home or at a library and make notes or print copies of thematerials to then take shopping with them. The disadvantage with thisapproach is that the consumer may be using stale data when attempting tomake the purchase at the merchant's location. Alternatively, a consumertrying to avoid using stale data in facilitating a purchase may attemptto ask various merchants for the latest pricing and selection options ofthe desired product. This later approach has a disadvantage in that itdoes not use the consumer's time efficiently.

[0008] In the example above, the consumer would be better served if theyemployed wireless computing devices to ensure that the latest data ispresented to them in the most efficient manner. In order to present aconsumer with relevant information, the wireless device should be ableto determine the environmental context that the consumer operating inthe example. Where environmental context refers to the physicalenvironment in which the consumer is operating, here a mall or aparticular store within a mall. In addition, the wireless device shouldbe able to sort available information so that a consumer is onlypresented with information that is relevant only to their interests.

[0009] Prior art techniques for determining environmental context relyon the wireless device for processing information to determine position;or they use the infrastructure (i.e.ground based transmitters) toprocess information received from a wireless device to establish itslocation. When the wireless device processes data to establish position,global positioning receivers (GPS) receivers are normally used. Some ofthe disadvantages associated with GPS receivers are that they requireadditional power and do not work well indoors. When the networkinfrastructure attempts to determine position, radio-frequency (RF)ranging techniques are used. RF ranging techniques normally employbeacons that transmit data to and receive data from wireless device.Some of the disadvantages associated with RF beaconing techniques arethat their locational accuracy is not very good and the wireless deviceconsumes excessive power when transmitting beacon signals or whenprocessing received beacon signals.

[0010] Prior art techniques for communicating data to wireless devicesalso have shortcomings. RF signals are the primary means fortransmitting data to wireless devices. Cellular, wireless Ethernet,Bluetooth™, and microwave are some of the most common prior art methodsfor communicating data to wireless devices. These forms of communicationalso consume large amounts of power.

[0011] It is thus an object of the present invention to deliver servicesto a wireless handheld device operating in a constrained networkingenvironment.

[0012] A further object of the invention is that a service delivers anadvertisement to a handheld device so that a user can make a decisionregarding the service.

[0013] It is still a further object of the invention that informationcontained in an advertisement relating to a service be displayed to auser of a wireless handheld device if the user has expressed an interestin the service.

SUMMARY OF THE INVENTION

[0014] Embodiments of the present invention employ apparatus, computerprogram product, method, and/or computer-readable-signal for deliveringservices in a constrained networking environment. More specifically, amethod for distributing an advertisement associated with a service to aclient device is provided. An advertisement is propagated from atransmitter to the client device as an advertising signal containingadvertising information. The advertising signal is received at theclient device and decoded to extract the advertising information. Theadvertising information is displayed to a user of the client device.

[0015] In a further aspect of the invention, a method for conveying anadvertisement from a transmitter having a link layer is provided. Anadvertisement is received from a service. The advertisement is formattedfor transmission to a client device operating within a contextassociated with the transmitter. Then the advertisement is conveyed tothe client device over a communication medium. In an alternativeembodiment, the advertisement is comprised of an XML element. In yetanother embodiment, the advertisement includes service information forenabling a user of the client device to make a decision about theservice, data entry information for informing the user about utilizingthe service, and contact information containing instructions forenabling the client device to communicate with the service.

[0016] In yet a further aspect of the invention, a method for receivingan advertisement from a transmitter having an emitter link layerassociated therewith is provided. The advertisement is received at acommunication interface. The advertisement is then decoded to extractinformation contained therein. Extracted information is processed andthen displayed to a user. In an alternative embodiment, the emitter linklayer in the transmitter is compatible with a client device link layerassociatively coupled to the communication interface. In yet anotheralternative embodiment, information is displayed to a user using aplug-in cooperatively associated with the advertisement.

[0017] In still another aspect of the invention, a method of utilizingexecutable code in a transmitter for providing an advertisement to aclient device operating within a coverage area associated with thetransmitter is provided. The executable code causes the transmitter toreceive the advertisement from a service provider, format theadvertisement for transmission to the client device, and convey theadvertisement from the transmitter to the client device over acommunication medium.

[0018] It is advantageous to employ embodiments of the present inventionfor delivering services to a handheld device in a constrained networkingenvironment. A further advantage of the present invention is that ahandheld device operating within a given context may make a decisionregarding a service based on an advertisement. Still a further advantageof the present invention that information contained in an advertisementfor a service be displayed to a user of a handheld device if the userhas expressed a preference for the service.

[0019] Further objects and advantages of the present invention willbecome more apparent after reference to the detailed description ofexemplary embodiments thereof taken in conjunction with the accompanyingdrawings in which:

BRIEF DESCRIPTION OF THE DRAWINGS

[0020]FIG. 1A and B are schematic diagrams of a system for transmittingcontext to a handheld device;

[0021]FIG. 2 is a schematic diagram of a general purpose computer thatmay be configured to practice embodiments of the invention;

[0022]FIG. 3 is a block diagram showing examples of unidirectionalcommunication signals that may be employed with embodiments of theinvention;

[0023]FIG. 4A and B are schematic diagrams showing an exemplary datasignal that may be received by a client;

[0024]FIG. 5 is a timing diagram illustrating the relationship betweensignals that may be used with embodiments of the invention;

[0025]FIG. 6 is a block diagram illustrating exemplary bi-directionaldata structures that may be employed in the invention;

[0026]FIG. 7 is a schematic diagram illustrating exemplary clientmodules and their respective interconnections;

[0027]FIG. 8A and B are flowcharts showing operation of a communicationmodule operating in a client device;

[0028]FIG. 9 is a block diagram illustrating states of the communicationlibrary module that may be used for practicing embodiments of theinvention;

[0029]FIG. 10A and B are flowcharts illustrating an exemplary integritychecking state;

[0030]FIG. 11 is a flowchart showing an exemplary create XML state;

[0031]FIG. 12 is a flowchart showing an exemplary context behaviormodule;

[0032]FIG. 13 is a flowchart showing an exemplary banner display module;

[0033]FIG. 14 is a block diagram illustrating exemplary service objectsthat may be created in a client device;

[0034]FIG. 15 is a flowchart showing an exemplary service factorymodule;

[0035]FIG. 16A, B and C are flowcharts showing operation of an exemplaryservice container module;

[0036]FIG. 17 is an exemplary client device and display;

[0037]FIG. 18 is a flowchart showing an exemplary service displaymodule; and,

[0038]FIG. 19 is a flowchart showing an exemplary interaction between aclient device and a service.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0039] The disclosed invention solves the problems of the prior art bydelivering contextually relevant information to a handheld device. Asused herein, context is comprised of two parts. The first part isenvironmental, or locational context. Locational context refers to aphysical location such as an isle in a department store, a seat in asporting complex, or a conference room in an office building, or thelike. The second part is referred to as a personal context as it relatesto a user's interests. Examples of a personal context for a particularuser are books by a particular author, a particular size or style ofclothing, and departure times for flights to a particular destination.Embodiments of the disclosed invention may make use of both locationaland personal context when making information available to a user of ahandheld device. As previously noted, prior art techniques force thehandheld device to determine context using onboard sensors or byperforming complex processing tasks. In the disclosed invention,locational context is pushed to the handheld device. Pushing locationalcontext using the network infrastructure lets a service deliver relevantcontent to wireless users while greatly reducing the processing andpower demands placed on a handheld device.

[0040] To aid the reader in understanding the disclosed invention,examples are periodically used herein. These examples are intended to beillustrative and non-limiting; therefore, the examples should not beconstrued in a manner that limits the scope of disclosed embodiments oralternative embodiments in any way.

[0041]FIG. 1A illustrates an overall architecture that may be used forpracticing disclosed embodiments of the invention. In particular, FIG.1A shows system 100 comprising service providers 102, 102 a, network104, controller 106 comprising broadcast information (BI) controller 106a and service controller 106 b, one or more emitters 108, one or morepoints-of-presence (POPs) 110, and one or more client devices 112. Asused herein client, or client device, will be used to identify ahandheld device capable of receiving contextually relevant information,and user will identify a person operating a client or making use ofinformation contained in a client device.

[0042] Service provider 102 is communicatively coupled to network 104 bylink 114. Service provider 102 is an entity wishing to provide a serviceto client device 112. Typically, service provider 102 will include acomputer executing software enabling it to provide services of interestto a user of client 112. Examples of services that may be provided are,but are not limited to, credit card purchase validations, onlinecatalogs, online banking information, travel planning information,medical information and the like. Additionally, service provider 102 mayoperate individually to provide services to a user, or alternatively, itmay operate in concert with other service providers when servicing auser.

[0043] Links 114 are communication media allowing devices coupled tonetwork 104 to communicate with one another. Typically, links 114 may becomprised of optical fiber; however, they may also be comprised ofcoaxial cable, twisted pair wire, an RF link 116, or the like.

[0044] Network 104 may be comprised of a plurality of links 114 or 116and network components (not shown) for facilitating the movement ofcommunication signals from an originating point to a termination point.Examples of network components that may be used in conjunction withlinks 114 and 116 for facilitating communications are, but are notlimited to, routers, switches, bridges, gateways, firewalls, and thelike. For many embodiments of the invention, network 104 will becomprised of a public network such as the Internet employing transportcontrol protocol/Internet protocol (TCP/IP). However, the invention isnot limited to a single network, nor is it limited to a particular typeof network or to a network operating with a single protocol. Forexample, the invention may be practiced with private networks such asvirtual private networks (VPNs), or local area networks (LANs) coupledto a public network such as the Internet. In addition, network 104 mayoperate with virtually any network protocol such as asynchronoustransfer mode (ATM), synchronous optical network (sonet), frame relay,or the like, or, alternatively, network 104 may operate with wirelessprotocols such as code division multiple access (CDMA), time divisionmultiple access (TDMA), wireless Ethernet, or the like. Thus theinvention is very flexible with respect to network implementations andprotocols.

[0045] In FIG. 1A, network 104 conveys data from service provider 102 tocontroller 106. Although network 104 is shown coupling service provider102 to controller 106, it may also connect controller 106 to emitter 108and to POP 110 in other embodiments.

[0046] Controller 106 may be comprised of a computer executing softwarefor providing the functionality of a service controller 106 a and abroadcast information controller 106 b. It is noted that controller 106may incorporate additional functionality and it may be implemented in adistributed fashion rather than as the single entity shown in FIG. 1A.Service controller 106 a ensures that data exchanges between serviceprovider 102 and controller 106 are properly handled. For example,service controller 106 a may perform error detection and correction,data encryption, transport protocol conversion, and the like. Serviceprovider 102 and service controller 106 a may communicate using anymutually agreed upon data protocol.

[0047] Broadcast information controller 106 b handles the distributionof broadcast information, referred to as a broadcast to emitter 108 andPOP 110 for distribution to client 112. As used herein, the termbroadcast, or broadcast signal, denotes a one-way communication signalgoing from an originating location to a terminating location. Broadcastsmay be directed to a single termination point, for example to a specificemitter in a known location, or they may be transmitted to a pluralityof termination points. Furthermore, broadcast signals may be conveyedover a wire line communication medium or a wireless communicationmedium. In a preferred embodiment, broadcasts are comprised of a seriesof extensible markup language (XML) elements containing information ofinterest to a user of client 112. Use of XML elements in conjunctionwith embodiments of the invention will be later described herein.

[0048]FIG. 1B provides a more detailed illustration of emitter 108, POP110 and client 112 shown in FIG. 1A. The primary distinction betweenemitter 108 and POP 110 is that emitter 108 performs one-way wirelesstransmission to client 112 whereas POP 110 performs one-way wirelesstransmission to client 112 and in addition, may perform two-waycommunications with client 112. In the foregoing discussions, emitter108 will be used to describe and reference the hardware, software, andmethodology associated with performing one-way wireless transmission. Assuch, it is intended that emitter 108 will also refer to the one-waywireless transmission capabilities of POP 110.

[0049] Emitter 108 may receive a broadcast containing XML elements fromcontroller 106 before converting it into a wireless communication signalfor transmission to client 112. In a preferred embodiment, emitter 108conveys information to client 112 via optical radiation. Typically,emitter 108 is placed at a known location and is designed to have agiven coverage area. As used herein coverage area refers to thevolumetric region that a broadcast penetrates, for example a room,stadium, or store isle. More specifically, for a given emitter 108, thecoverage area defines the space over which client 112 can receive thebroadcast signal and hence locational context information containedtherein.

[0050] To assist the reader in understanding operation of the disclosedinvention, a general non-limiting example will be used through out thespecification. In this example, an airline will comprise serviceprovider 102. Operation of the airline as a service provider will bediscussed in conjunction with operation of selected embodiments of theinvention. The example will further include locational contexts such asB-wing at Logan Airport and particular gate areas. In addition, theexample will include personal context items such as flight numbers andseat numbers.

[0051] Using the airline example, emitter 108 may be located in aparticular wing of an airport, here B-wing of Logan Airport.Furthermore, emitter 108 may be designed to transmit a signal over aspecified area, here the waiting area for B-wing at Logan. Furthermore,the airline may transmit a signal to controller 106 containinginformation about all departures from B-wing leaving within a certaininterval of time. Controller 106 may format departure information intoone or more XML elements and transmit them as a broadcast to an emitter108 located in the B-wing waiting area. Emitter 108 then transmits thedeparture information to a client 112 located within the waiting area ofB-wing. A user of client 112 may then make travel arrangements based onthe displayed contextually relevant information.

[0052] Returning to FIG. 1B, in conjunction with FIG. 1A, emitter 108and POP 110 are comprised largely of the same hardware and softwarecomponents. The primary distinction between the two is that POP 110 canreceive transmissions from client 112 over PDA interface 131. PDAinterface 131 may be an electromechanical interface, such as a bus orconnector, or it may receive a wireless reply signal 143 from client112. Like emitter 108, POP 110 may be placed at a known location, have adefined coverage area, and may transmit a wireless signal such as anoptical signal.

[0053] Network interface 120 receives a broadcast signal from controller106 via link 114 or wireless link 116. Next, buffer 122, 122 a maybuffer incoming data to balance variations between the data rate atnetwork interface 120 and optical transmitter 128 to prevent overwritingdata awaiting transmission from emitter 108. In addition, buffer 102 aperforms buffering of data received at PDA interface 131 before placingit on link 114. Data formatter 124 receives data from buffer 122, 122 aand performs data conversions needed to transform the received broadcastinto a signal compatible with IR communications interface 130 on client112. For example, data formatter 124 may convert a received broadcastinto a format for optical transmission to client 112. From dataformatter 124, the signal goes to IR port driver 126. IR port driver 126performs amplification and signal conditioning necessary fortransmission of broadcast signal as optical radiation. Opticaltransmitter 128 receives formatted broadcast data from IR port driver126 and transmits it as an optical signal 142 to client 112.

[0054] Client 112 may be comprised of a handheld wireless device. Client112 may be equipped with one or more types of wireless communicationmeans such as an optical transceiver, cellular transceiver, or other RFtransceiver such as IEEE 802.11 or Bluetooth™. Most often, client 112will be a commercially available personal digital assistant (PDA) suchas the Palm Pilot™ from Palm Computing or a handheld computer such asiPAQ Blackberry™ from Compaq Computer Corporation. As used hereinafter,PDA and client 112 will be used to refer to handheld devices used inpracticing embodiments of the invention. Client 112 may be comprised ofan infrared (IR) communication interface 130, a input/output module 132,an XML parser 134, a processing module 136 and display 139.

[0055] IR communication interface 130 receives optical signal 142. Thereceived signal is converted from optical to electrical form and sent toinput/output module 132. Input/output module 132 performs signaldemodulation, amplification and filtering for incoming signals andperforms the inverse for outgoing data. Next, the received signal ispassed to XML parser 134, which breaks the signal into its componentparts for use by processing module 136. Processing module 136 performsprocessing necessary to get the received data into a form useful to auser of client 112. From processing module 136, the received data isdisplayed to a user of client 112 by display 139. User inputs 140 can beentered into client 112 through display 139 using a stylus, touchsensitive display, or the like.

[0056] Returning again to the airline example, information displayed toa user in B-wing at Logan Airport may indicate the gate numbers andcorresponding departure times for flights leaving B-wing. User inputs140 may be accepted by display 139 and locally processed on client 112or they may be formatted and transmitted to POP 110 via PDA interface131.

[0057]FIG. 2 illustrates an exemplary computer 220 on, or with, whichembodiments of the disclosed invention may be used, namely serviceprovider 102, controller 106, emitter 108, POP 110 and client 112. InFIG. 2, exemplary computer 220 includes a processor 202, main memory204, read only memory (ROM) 206, storage device 208, bus 210, displaydevice 212, keyboard 214, cursor control 216, and communicationinterface 218.

[0058] Processor 202 may be any type of conventional processing devicethat interprets and executes instructions. Main memory 204 may be arandom access memory (RAM) or a similar dynamic storage device. Mainmemory 204 stores information and instructions for execution byprocessor 202, and main memory 204 may also be used for storingtemporary variables or other intermediate information during executionof instructions by processor 202. ROM 206 stores static information andinstructions for processor 202. It will be appreciated that ROM 206 maybe replaced with other types of static storage devices known in the art.Data storage device 208 may include any type of magnetic or opticalmedia and corresponding interfaces, operational hardware, andcarrier-waves. Data storage device 208 stores information andinstructions for use by processor 202. Bus 210 includes a set ofhardware lines (conductors, optical fibers, or the like) that allow fordata transfer among components of computer 220.

[0059] Display device 212 may be a cathode ray tube (CRT), or the like,for displaying information to a user. Keyboard 214 and cursor control216 allow a user to interact with computer 220. Cursor control 216 maybe, for example, a mouse. In an alternative configuration, keyboard 214and cursor control 216 may be replaced with a microphone and voicerecognition means to enable a user to interact with computer 220 in ahands free manner. For embodiments of computer 220 used in POP 110 andemitter 108, display 212, keyboard 214 and cursor control 216 willnormally be omitted. Furthermore, for embodiments of computer 220 usedin client 112, keyboard 214 and cursor control 216 may be replaced witha stylus (not shown) and a touch sensitive embodiment of display 139.

[0060] Communication interface 218 enables computer 220 to communicatewith other devices or systems via any communications medium. Forexample, communication interface 218 may be a modem, an Ethernetinterface to a LAN, an optical radiator, an RF transmitter, a printerinterface, or the like.

[0061] Computer 220 may be adapted and modified to fulfill requirementsassociated with embodiments such as service provider 102, controller106, emitter 108, POP 110 and client 112. For example, computer 220 maybe embodied as a network server at service provider 102 or controller106 for facilitating communications over network 104. In emitter 108 orPOP 110, computer 220 may be embodied as an application specificprocessor for receiving data from controller 106 and formatting it intoa wireless signal for transmission to client 112. In client 112,computer 220 may be embodied in a configuration minimizing size andpower consumption at the expense of processor speed and system memory.As can be seen, computer 220 is adaptable using techniques known in theart for practicing embodiments of the disclosed invention.

[0062] Controller 106 serves as the interface between service provider102, emitter 108, and POP 110. The primary purpose of controller 106 isto receive data from service provider 102 and make it available toemitter 108 in a format easily transmitted to client 112. In addition,data received at client 112 is formatted in such a way that client 112can extract relevant information without undue processing. Controller106 performs its function by receiving service-provider-data at servicecontroller 106 a. Service controller 106 a then passes theservice-provider-data to broadcast information controller 106 b.Broadcast information controller 106 b is responsible for placingservice-provider-data into a message format that is easily processed byclient 112.

[0063] In most embodiments of the invention, emitter 108 will operateessentially as a data repeater with respect to broadcast informationreceived from controller 106. As a repeater, emitter 108 converts datapresent at network interface 120 into optical radiation at opticaltransmitter 128. When operating as a repeater, emitter 108 may notperform any additional processing on broadcast information messages,other than performing routine error detection and correction. Emitter108 operating in this capacity is referred to as a dumb emitter. Use ofa dumb emitter makes it possible to deploy less costly wireless networksfor sending information to client 112.

[0064] When a dumb emitter is used, the data structures sent fromcontroller 106 to emitter 108 will appear at the output of opticaltransmitter 128. Broadcast information controller 106B formats data intoa series of structured XML elements prior to making them available toemitter 108. The use of XML elements for carrying data to client 112facilitates efficient processing and extraction of information containedtherein when received at client 112.

[0065] In a preferred embodiment of the invention, contextualinformation is efficiently provided to client 112 using XML elementsand/or XML documents. An XML document is comprised of data and tags.Data is the actual content within a document and an example of data ischaracter text. Tags are used to denote the structure, or format, ofdata within an XML document. XML elements serve as the fundamentalcomponents of an XML document and they may contain data or otherelements, referred to as sub-elements. Since elements are often nested,the term root element is used to identify the element that is notcontained within any other element in a given XML document.

[0066] In an XML document, tags are surrounded by markups which are openand closed brackets, “<” and “>”, respectively. Tags serve as handlesfor identifying elements within an XML document. For example, a tag foridentifying an airline may appear as <airline>. As such, tags make XMLdocuments easy to parse using readily available parsers. When elementsare parsed, other software routines, modules, or applications may usethe data contained in, or referenced by them.

[0067] Referring to the airline example, an airline acting as serviceprovider 102 may employ tags within one or more XML documents associatedwith available services, namely particular flights. An exemplary, andnon-limiting, hierarchy of tags for an XML document may appear as:<airline name> <airport name> <airport wing> <gate number> <flightnumber> <seat number>

[0068] From the example, it can be seen that airline name is the rootelement and the subelements below it describe aspects about the servicein greater and greater detail. If sending contextual information to auser located at a particular gate, e.g. gate 16 in the B-wing of LoganAirport, the tags facilitate parsing by the infrastructure (controller106 and emitter 108) so the user receives only relevant information.

[0069] Broadcast information is comprised of three primary XML elementtypes, hereinafter referred to as BI XML elements.

[0070]FIG. 3 presents exemplary BI XML elements, which include a bannerelement 302, a service element 304, and a context element 306. BI XMLelements are unidirectional communication signals in that they travel inonly one direction, namely from controller 106 to emitter 108 and thento client 112. Banner element 302 may be used for making a ticker tapelike display appear on display 139 of client 112. When client 112receives banner element 302, any information contained therein isdisplayed to a user of client 112. Since the location and coverage areaassociated with emitter 108 are used to control distribution ofinformation only to areas where it is contextually relevant, client 112does not perform any processing on banner element 302 to discern itscontents. As such, any banner element 302 received at client 112 will bedisplayed to a user. Typically, banner element 302 is useful for makingbrief messages available to client 112.

[0071] Returning to the airline example, banner element 302 may be usedto display flight numbers and departure gates to a user located withinthe coverage area of the emitter in B-wing at Logan.

[0072] Although banner element 302 is primarily used for making briefmessages available to client 112, it is not limited to those. Forexample, a number of banner elements 302 may be used to makesubstantially continuous messages available to client 112. Such acontinuous banner message may occur, for example, if a speaker'spresentation is converted to text for display to clients 112 locatedwithin the coverage area of one or more emitters 108 associated with thepresentation.

[0073] Service element 304 may be used to provide electronic services toclient 112 located within a particular context. Service element 304typically describes a service that is available to a user located withina particular context. More specifically, service element 304 dynamicallydescribes a service to client 112. When received at client 112, serviceelement 304 contains enough information to uniquely identify the offeredservice and to provide information needed for contacting the service.

[0074] Returning to the airline example, service element 304 may providea client 112 within B-wing with electronic forms allowing them to changeflights, obtain boarding passes, reserve concierge services, etc.

[0075] Context element 306 is very versatile. The specific structure andcontent of context element 306 depends on the environment that emitter108 is deployed in. Context element 306 may serve as a wrapper aroundother BI XML elements. For example, context element 306 may be used toencapsulate another BI XML element such as banner element 302 or serviceelement 304. When used to encapsulate another BI XML such as bannerelement 302, context element 306 provides a mechanism for allowingclient 112 to discern if it wants to make the information in the bannerdisplay available to a user.

[0076] Returning to the airline example, encapsulating a banner element302 for indicating departures times and gates in a context element 306directed to showing flights with available seats provides client 112with a means for only displaying departures having available seats to auser wanting such information.

[0077] Employing unidirectional signals such as BI XML elements may poseproblems, namely error detection and correction at a receiving devicesuch as emitter 108 or client 112. The disclosed invention overcomesthis shortcoming by performing error detection for unidirectionalsignals using a special type of XML element called an integrity element.An integrity element is used by the infrastructure, such as emitter 108,or by client 112 to ensure proper reception of BI XML elements. In apreferred embodiment of the invention, each root XML element may beencapsulated in an integrity element when transmitted from controller106 to emitter 108 or client 112.

[0078]FIG. 4A illustrates integrity element 402, 404 and 406 which isused to perform error detection for BI XML elements. Exemplary BI XMLelements are shown as bytes 1A-4A, 1B-4B and 1C-4C which are groupedinto window A 401 a, window B 401 b, and window C 401 c, respectively.The bytes are comprised of bits of data containing information fromservice provider 102. Information may be comprised of an advertisementfor a service provided by service provider 102 or, alternatively,information may include the service itself as executable code orequivalent. The grouping of BI XML bytes located within an integrityelement is referred to as a window, or frame.

[0079] Broadcast information controller 106 b may parse an exemplarymessage into bytes 1A-4A, 1B-4B, 1C-4C for transmission to emitter 108.Then, broadcast information controller 106 b encapsulates the resultingwindows 401 a, 401 b, 401 c with integrity element 402, 404, 406,respectively. Integrity element 402, 404, 406 may contain a header 403having a checksum value 407, a window size 408, an operator 410, and aseed 412. Checksum value 407 is computed over the bytes making up arespective window 401 a, 401 b, 401 c using known techniques such asexclusive ORing (XORing) each byte with its neighbor. As such, checksumvalue 407 uniquely identifies the contents of the window 401 a, 401 b,401 c over which it was computed. Window size 408 identifies the numberof bytes that checksum value 407 was computed over. Operator 410identifies the mathematical operator used to compute checksum value 407,and seed 412 identifies the seed value used for computing the firstvalue used when computing checksum value 407. Seed 412 may be set tozero if no seed value is used.

[0080] Here it is noted that a time element (not shown in FIG. 4), ortimestamp, may be included in window 401 a, 401 b, 401 c. If used, atime element contains data allowing emitter 108, POP 110 or client 112to determine a time relative to some reference. For example, a timeelement may provide time with respect to Greenwich Mean Time (GMT), amaster clock within network 104, or a timer within emitter 108. Use of atime element further enhances the context associated with client 112because it allows client 112 to establish a temporal context in additionto the locational and personal context already described herein.

[0081]FIG. 4B illustrates the resulting broadcast information streaminside client 112 after integrity elements 402, 404 and 406 have beenremoved by XML parser 134. The details associated with receiving andextracting integrity elements from a received signal will be discussedin more detail in conjunction with the detailed description of client112 discussed later herein. When integrity elements 402, 404 and 406 areremoved, the original data stream containing banner elements 302,service elements 304, context elements 306, or other data remain. Theellipses used in FIG. 4B indicate that the broadcast information streammay be substantially endless i.e. it may continue beyond that shown inFIG. 4B.

[0082] In more complex embodiments of the invention, emitter 108 may beconfigured to accept messages in virtually any format. If configured assuch, emitter 108 may be equipped with processing hardware and softwarefor converting incoming data into an XML based message for transmissionto client 112.

[0083] As shown and discussed in conjunction with FIG. 1B, emitter 108contains the hardware and software necessary to convert electricalsignals into optically radiated signals. When setting up aninfrastructure for practicing the invention, placement of emitters 108and POPs 110 is very important because their respective coverage areasdetermine the locational context for clients 112 located therein. Sinceemitter 108 may be configured as a dumb emitter, having essentially noprocessing capability or configured as a smart emitter having processingcapability, they provide a network designer with great flexibility.

[0084] Dumb emitters are small in size and inexpensive to build,therefore they can be deployed in larger numbers, thus allowing forsmaller coverage areas within a given environment. Use of small coverageareas allows the infrastructure to better refine the locational contextassociated with a given emitter 108. Refined locational context allowsrelevant information to be provided to a user in a more reliable manner.

[0085] Returning to the airline example, if low cost emitters aredeployed near each boarding gate in B-wing, then a user located withinthe coverage area of a gate emitter may only receive information dealingwith departures from the respective gate. Using emitters with smallcoverage areas further reduces the processing demands on client 112 thusallowing less expensive and less capable PDAs to benefit from theinvention.

[0086] Smart emitters may be incorporated where it is desirable to movethe processing out of the infrastructure portion that includescontroller 106 and place it into emitter 108. For example, it may bebeneficial to employ smart emitters when a general-purpose network notemploying BI XML elements is providing raw data to particular locations.When smart emitters are used they may employ virtually any communicationprotocol for receiving data from network 104 and controller 106. In sucha configuration, emitter 108 receives raw data and performs necessaryfiltering and processing to extract contextually relevant informationusing data formatter 124. Data formatter 124 then converts thecontextually relevant information into the necessary BI XML elements.Next, the information is passed to IR port driver 126 and then tooptical transmitter 128 for transmission to client 112 as optical signal142.

[0087] When transmitting optical signals to client 112, emitter 108 mayemploy virtually any waveform generated using known modulation methods.Examples of modulation methods usable for transmitting optical signalscompatible with embodiments of the invention are, but are not limitedto, baseband pulsing, frequency shift keying (FSK), amplitude shiftkeying (ASK), phase shift keying (PSK), pulse position modulation (PPM),or burst-PPM. In addition, emitter 108 may transmit optical signals ofvirtually any wavelength.

[0088] Although emitter 108 is very robust, it will normally be designedto leverage off of existing optical communication protocols and hardwareused in client 112. Two of the most common optical communicationprotocols used in conjunction with inexpensive electronic devices, suchas PDAs, laptop computers, cell phones, and the like, are those referredto as the diffuse optical communication protocol and theinfrared-data-association (IrDA) communication protocol. Both of theseprotocols employ near infrared signals, where infrared denoteswavelengths of light that are too short for visual perception by humans.

[0089] The diffuse optical communication protocol is primarily used forsetting up optical local area networks over small areas such as aclassroom or auditorium. The primary distinction between diffuse opticalcommunications and IrDA communications is that the former allows formany-to-many communications such as in a network and the later allowspoint-to-point, or one-to-one, communication. Advantages of diffuseoptical signals are that they may offer either bi-directional orunidirectional communication capability. In addition, a diffuse opticalsignal can be used to accomplish communication when non-line-of-sightgeometries are present. An example of a non-line-of-sight geometry iswhen a transmitter is located such that a straight line drawn from it toa receiver intersects a barrier before reaching the receiver. Such ageometry would exist if a cubicle wall was located between an opticaltransmitter attached to a ceiling and a laptop located on a desk withinthe cubicle.

[0090] Non-line-of-sight communications are possible because a diffuseoptical signal can bounce off obstructions and thus be reflected to areceiver. Using the cubicle wall example, a diffuse signal can bounceoff the ceiling and walls to reach the laptop even though aline-of-sight path from the optical transmitter to the laptop is notpresent. Diffuse transmitters normally use arrays of LEDs to transmitnear-infrared signals having wavelengths in the range of 850 nanometers(nm) to 1250 nm. When used to accomplish one-way communications, adiffuse optical transmitter does not receive any acknowledgement from areceiver, thus ensuring reliable one-way communications is difficultunless the receiver has a clear line-of-sight path to the transmitterthat is not likely to encounter any inferences that could distortreceived data.

[0091] The IrDA protocol was developed by a non-profit trade associationrepresenting companies that make computer and telecommunicationshardware and software. The protocol is defined in an IrDA standard whichis already employed in several million devices such as PDAs, laptops,and the like. As a result, leveraging off of IRDA capable devices isvery desirable for implementing cost effective contextually relevantcommunication systems. As previously noted, IRDA protocol is forone-to-one optical communications that are directional in nature andoccur over very short ranges. Specifically, IRDA transmitters have abeam that extends roughly ±15° from the main transmission axis. As aresult, two IrDA devices must have their respective infrared data portspointed toward each other for communications to occur. In addition, IrDAdevices should be within 1 meter of each other to ensure reliablecommunication. Reliable communication using IrDA devices also requiresthat the devices perform handshaking when communicating.

[0092] Handshaking is used to describe the acknowledgements sent betweencommunicating IRDA devices for ensuring reliable communication. The IrDAspecification indicates proper handshaking requires that a deviceattempt to send data for at least 100 ms. If no acknowledgement isreceived after 100 ms, then the sending device may stop transmitting.Additionally, the IRDA standard also defines a media busy state. Themedia busy state requires that a device observe its IR port for 500 msbefore transmitting if it has not already established a communicationsession with another device. If no signal is detected for 500 ms thenthe device waiting to transmit can begin sending infrared data. Likediffuse infrared signals, IrDA compliant signals typically havewavelengths between 850 and 1250 nm.

[0093] The IrDA standard also defines a protocol stack for facilitatingcommunication by applications running on IrDA equipped devices. Theprotocol stack breaks the IrDA communication protocols into layers. Eachlayer deals with a manageable set of responsibilities and suppliesneeded capabilities to the layers above and below. The IrDA standardidentifies both mandatory and optional protocol layers. Here themandatory protocol layers will be discussed beginning with the bottomlayer. The mandatory protocol layers are the physical layer, link access(LAP), link management (LMP), and information access service (IAS). Ofthe mandatory protocol layers, the physical layer and link layer arepertinent to an understanding of the disclosed invention and they willbe further discussed.

[0094] The physical layer specifies the optical characteristics, theencoding of data, and the framing of data for various speedcommunications. It includes the optical transceiver, deals with theshaping of the optical signals, handles the encoding of bits within atransmitted signal, and handles the beginning of frame (BOF), end offrame (EOF) flags, and cyclic redundancy checks (CRCs). Normally thephysical layer is implemented in a combination of hardware and software;however it may be implemented solely in hardware if desired.

[0095] The LAP establishes the basic reliable connection; it receivesdata from and passes data to the physical layer. In order to isolate theLAP, and the layers above it from the hardware, a framer is employedbetween the physical layer and LAP. The framer is a software layer andit accepts incoming frames from the physical layer and makes themavailable to the LAP and does the reverse for transmitted data. The LAPcorresponds to the open system interconnection (OSI) data link protocoland it is responsible for retransmissions, low level flow control, anderror detection. Making the LAP responsible for reliable data transferfrees the upper layers from the task and ensures that reliable data willbe delivered to the layers above the LAP.

[0096] The invention takes advantage of the benefits of the diffuseinfrared protocol and the benefits of IRDA protocol while avoiding manyof their respective shortcomings. In particular, the invention transmitsdiffuse infrared signals to a client 112 having an IRDA compliantbi-directional communication interface. The invention accomplishescommunication by replacing the diffuse link layer with an IrDA compliantlink layer. Since the physical layers are essentially the same fordiffuse infrared and IRDA compliant systems, compatible link layers makeit possible for received data to be handled by client 112.

[0097] In client 112, conventional IrDA protocol layers above the linklayer are designed to handle two-way communication. If left in place,these layers would interfere with the reception and processing ofunidirectional infrared signals at client 112. The invention solves thisproblem by replacing layers above the link layer with software modulesdesigned to process unidirectional signals. Discussion of the softwaremodules used to process unidirectional signals in client 112 will befurther discussed in conjunction with the detailed description of client112 later herein.

[0098] The invention also utilizes a unique transmission scheme thatallows IrDA compliant communications to occur when diffuse infraredtransmissions are not being received at client 112. Gated transmissionsfrom emitter 108 are used to facilitate IRDA-to-IrDA communications whenclient 112 is not receiving signals from emitter 108.

[0099]FIG. 5 illustrates a diffuse signal and an IrDA retry interval asused in an embodiment of the invention. In particular, FIG. 5 shows adiffuse infrared emitter signal 502 having an emitter-on-interval 504and an emitter-off-interval 506, and an IrDA compliantclient-retry-signal 508 having a retry-on-interval 512 and aretry-off-interval 510.

[0100] Emitter signal 502 is comprised of 20 ms emitter-on-intervals 504separated by emitter-off-intervals 506. In a preferred embodiment,emitter-off-interval 506 is 980 ms in duration, resulting in oneemitter-on-interval every second. Emitter signal 502 transfers data to areceiving device, such as client 112, during emitter-on-interval 504,and does not transfer data to a receiving device duringemitter-off-interval 506.

[0101] Client-retry-signal 512 may occur in periodic pulse trains asneeded to maintain IrDA-to-IrDa communications between two clientdevices. As shown in FIG. 5, retry-on-interval 512 is 100 ms in lengthin compliance with the IRDA standard. If emitter-on-interval 504 ispresent at IR communication interface 130 when a client 112 is receivingdata, then the two pulses will only overlap by 20 ms in a worst casescenario. A 20 ms overlap provides client 112 with 80 ms to establish,or reestablish, communications with another IrDA compliant device. Inmost applications 80 ms is sufficient to allow client 112 to reestablishcommunication. As such, the presence of emitter signal 502 at IRcommunication interface 130 when client 112 is attempting to transmit orreceive will not significantly degrade IrDA-to-IrDA communications.

[0102] Limiting emitter signal 502 to 20 ms pulses may increase the timeneeded to convey a complete message to client 112 using the invention;however, the additional time needed will not generally be apparent to auser of client 112. If desirable, emitteron-interval 504 may beincreased in length and/or emitter-off-interval 512 may be shortened toprovide higher data communication rates if some additional delay inIrDA-to-IrDA communications can be tolerated. Thus the disclosed emittersignal 502 is very versatile for facilitating communications between adiffuse infrared transmitter and an IRDA compliant client 112.

[0103] As previously discussed herein, the distinguishing featurebetween POP 110 and emitter 108 is that POP 110 has a PDA interface 131for allowing client 112 to communicate with POP 110 or service provider102. Since POP 110 transmits locational context in addition to receivingclient data, it will often be located in areas frequented by client 112.Therefore, the physical configuration of POP 110 can be such that itfacilitates usage by client 112. In one embodiment of the invention, POP110 can take the form of a kiosk. A kiosk is an unattended structuredesigned to facilitate user interaction therewith. As used herein, akiosk provides client 112 with connectivity to network 104. Whendeployed as a kiosk, POP 110 may have a PDA interface 131 that is anelectromechanical interface for exchanging data with client 112. Anelectromechanical interface allows client 112 to plug into an electricalconnector over which data is exchanged. In an alternative embodiment theelectromechanical interface may be wireless interface. A wirelessembodiment of PDA interface 131 allows client 112 to communicate withPOP 110 using an RF or optical signal. POP 110 and client 112 may employvirtually any communication protocol for exchanging data using PDAinterface 131; however, in a preferred embodiment client 112 uses XMLbased elements to accomplish bi-directional communication with POP 110.

[0104] As discussed herein, the invention employs both unidirectionaland bi-directional communication signals to provide robust contextualcommunications between service provider 102 and client 112.Bi-directional communication signals are used by client 112 tocommunicate information to, and to receive information from, serviceprovider 102.

[0105]FIG. 6 illustrates a set of exemplary bi-directional communicationsignals comprised of XML elements. The invention is not limited to thesignals shown in FIG. 6; however the signals shown are useful forfacilitating efficient communication in a preferred embodiment. The XMLelements shown in FIG. 6 are broadcast information update data 602,client request data 604, service response data 606, client serviceproprietary communication data 608, service-to-service communicationdata 610, and miscellaneous data 612.

[0106] Broadcast Information Update (BIU) data 602 is used by controller106 to track the status of emitter 108. For BIU data 602 to obtain datafrom emitter 108, the emitter must be configured to provide statusinformation. Examples of useful status information that emitter 108 mayprovider are error data, status of optical transmitter 128, internaltemperature data, and power consumption data. Other parameters may betracked depending on the specific configuration of a system. In additionto tracking emitter status, BIU data 602 may be used to update smartemitters. For example, BIU data 602 can include software updates fordata formatter 124 or BIU data 602 may include new encryption protocolsfor network interface 120. As can be seen, BIU data 602 provides anefficient way to monitor and update emitter 108.

[0107] Client request data 604 is an XML element generated on client112. In client 112 services are represented as dynamically createdsoftware objects. Where a software object is a piece of softwaredesigned such that it accepts input data and makes output data availableaccording to an agreed upon format. Software modules external to theobject and wishing to communicate with it need only comply with theinput data or output data format. External modules do not have to beconcerned with the internal workings of the software object. Employingsoftware objects enables a software developer to re-use software objectsin new environments without having to redevelop large amounts ofsoftware. Client request data 604 is generated after a user hasinteracted with a service object on client 112. After client 112connects to POP 110 using PDA interface 131, client request data 604 isgenerated. An example of client request data 604 is information that auser of client 112 has entered in response to a banner display or othermessage displayed on display 139.

[0108] Returning to the airline example, if a banner message appears ondisplay 139 indicating that a user's flight is cancelled, the user maybe able to activate a flight change form by touching the banner display,or an icon associated therewith, using a stylus. Upon activating theflight change form, the user is asked to enter information such as newflight number, seating preferences, and payment method. Upon enteringthe information, the user plugs client 112 into POP 110 and sends theinformation to the airline. Client request data 604 is the XML elementused to convey the entered information to the airline.

[0109] Service response data 606 is the XML element generated by aservice provider in response to receipt of client request data 604.Depending on service provider 102, service response data 606 may containexecutable code for delivery to client 112, a reply to a question askedby client 112, an alert for display on display 139, an icon for displayon client 112, or the like. Typically, service response data 606 is onlyused during the initial contact between client 112 and service provider102. For example, if an icon and executable code have previously beendelivered to client 112, it may be desirable to have the icon andexecutable code associated with one another. If an icon and executablecode are associated with one another, then a user may be able toactivate a particular service by opening the associated icon forsubsequent uses of the service.

[0110] Client Service Proprietary Communication (CSPC) data 608 is usedby service provider 102 when communicating with client 112. For example,CSPC data 608 may be used to deliver executable code from serviceprovider 102 to client 112 after a user has interacted with an iconassociated with service provider 102. Use of CSPC data 608 allowsservice provider 102 and client 112 to interact in the most efficientmanner based on the type of service employed or task being accomplished.As such, CSPC data 608 will not normally be comprised of XML elements.But rather, CSPC data 608 will employ industry standard communicationprotocols such as TCP/IP or it may use special communication protocolssuch as encryption when carrying data over insecure networks.

[0111] Service-to-service communication (SSC) data 610 is the XMLelement used when one service provider must use another service providerto accomplish an interaction initiated by client 112. While theservice-to-service exchange will be based on the needs of client 112,the exchange itself does not have to involve client 112. In alternativeembodiments of the invention, service-to-service exchange may beaccomplished without using XML based elements or documents.

[0112] Returning to the airline example, if client 112 requests a newticket by sending client request data 604 to the airline, the airlinemay need to charge the passengers credit card. The credit cardvalidation and charging would take place between the airline and thecredit card company or a bank. As such, the airline and credit cardcompany communication may be accomplished using SSC data 610.

[0113] Miscellaneous data 612 is an XML element used to handle exchangesother than those identified above. For example, miscellaneous data 612may be used when a first client is communicating with a second clientusing one or more POPs 110. Miscellaneous data 612 may be used toexchange status data between two or more emitters 108 using link 114 orRF link 116. As can be seen, miscellaneous data 612 serves as ageneral-purpose bi-directional communication signal for embodiments ofthe invention.

[0114] As previously discussed, client 112 may be any type of portablecomputing device such as a PDA, handheld computer, or cell phone.Portable devices for use with the invention may take on many forms andhave varying levels of sophistication. For example, portable devices maycontain state of the art processors and large amounts of memory or, theymay have relatively slow processors and limited memory. In addition,portable devices may have other wireless communication capabilities, inaddition to bidirectional infrared communication interfaces. Examples ofother wireless communication capabilities are wireless Ethernet andcellular. Portable devices compatible with the disclosed embodimentswill also have various means for allowing a user to interact with thedevice. For example, a portable device may have a touch sensitivedisplay, a keyboard, a microphone for digitizing voice commands, atrackball, or the like. Although portable devices used with disclosedembodiments will vary to a large degree, all of them will operate inessentially the same manner when used to receive contextually relevantinformation consistent with the methods disclosed herein.

[0115]FIG. 7 illustrates the primary software modules and objectsoperating within client 112 for receiving and processing contextuallyrelevant information. Client software configuration 700 may be comprisedof a communication module 702 containing broadcast receiver 704;communication library module 707 containing listener queue 706; outgoingmessage queue 708; an XML parser 710 containing service tag 712, bannertag 714, location tag 716 and context tag 718; service factory module720; banner display module 722; context behavior module 724; servicecontainer module 730 containing services 1, 2 and 3; and service displaymodule 734. All of the modules receive inputs from other modules or sendoutputs to other modules using software communication means such asmessages or the like.

[0116] Communication module 702 is responsible for receiving data fromemitter 108 and sending data to POP 110 or other wireless device. Assuch, communication module 702 manages unidirectional and bi-directionalcommunications to and from client 112. Referring back to FIG. 1B,communication module 702 may be implemented as part of input/outputmodule 132 or IR communication interface 130 and it may include thefunctionality of XML parser 134.

[0117]FIG. 8A and B contain flow diagrams showing the operation ofcommunication module 702. In particular FIG. 8A illustrates a method forhandling unidirectional data received at IR communication interface 130and FIG. 8B illustrates a method for handling bi-directionalcommunications.

[0118] In FIG. 8A, communication module 702 may receive incomingbroadcast information via IR communication interface 130 and broadcastreceiver 704 (step 802). After receiving broadcast information,communication module 702 passes it to XML parser 134. XML parser 134parses the incoming message and removes integrity element 402. Afterremoving integrity element 402, XML parser 134 passes the broadcastinformation to the appropriate module (step 804). For example, if bannerelement 302 is received by communication module 702 it will be passed tobanner display module 722 if banner tag 714 is present. If service tag712 is present, XML parser 134 passes the broadcast information toservice factory module 720. If context tag 718 is present, XML parserpasses the broadcast information to context behavior module 724. Inaddition, location tag 716 may be used to confirm the location ofemitter 108 that is sending the message, or location tag 716 can be usedin conjunction with location sensors in client 112, such as GPS, to helpestablish the position of client 112.

[0119]FIG. 8B begins with client 112 determining if it is connected toPDA interface 131 at POP 110 (step 806). If client 112 determines thatit is not connected to PDA interface 131, the method stops and client112 operates in unidirectional mode (step 808). Upon sensing that client112 is connected to a bi-directional communications interface,communications module 702 receives data from software modules on client112, such as service factory module 720 (step 810). Next, communicationsmodule 702 may create an outgoing message queue 708 (step 812) beforetransmitting the data to POP 110 (step 814). After transferring data toPOP 110, communications module 702 receives data from service provider102 via PDA interface 131 (step 816). The received data is passed to theappropriate software module on client 112 (step 818).

[0120] Returning to the airline example, if a user completes a form forordering a new ticket, communication module 702 receives data fromservice display module 734 (step 810), queues the order message (step812) and sends the order message to POP 110 via PDA interface 131 (step814). Then, the airline processes the order and sends a confirmation andreceipt to client 112. The confirmation is received at client 112 viaPDA interface 131 (step 816) and it is passed to service display module734 (step 732) for presentation to the user.

[0121] Additional processes occur within communication module 702 whenperforming the methods shown in FIG. 8A and 8B. Before communicationmodule 702 receives messages and distributes them to other softwaremodules, the other software modules register with communication module702. In particular, software modules interested in receiving data fromcommunication module 702 register with a communication library module(CLM) 707 operating in conjunction with communication module 702. Whenmodules register with communication module 702, listeners are createdfor each module and maintained in listener queue 706. When communicationmodule 702 receives a message it looks for a listener registered for theparticular message type. If no registered listener is found in listenerqueue 706, the message is ignored or overwritten when new data isreceived by communication module 702.

[0122]FIG. 9 illustrates CLM 707 which may be comprised of states.Exemplary states that may be incorporated in CLM 707 are an open state904, a close state 906, a find integrity check (IC) element state 908, aperform integrity check state 910 and a create XML element state 912.Depending on the preferences of a designer, CLM 707 may be incorporatedinside communication module 702 or it may be designed as an externalmodule operating in conjunction with communication module 702.

[0123] Open state 904 is called when CLM 707 is initialized. Open state904 initializes an external communication medium and obtains memorynecessary for CLM 707 to operate. Examples of external communicationmedia are, but are not limited to, IR communication interface 130 or awireless RF interface such as Bluetooth™.

[0124] Close state 906 is called when CLM 707 is unloaded. Close state906 releases memory used by CLM 707. In addition, close state 906signals the broadcast medium, in the case of bi-directionalcommunications, that CLM 707 is closing.

[0125] Find IC element state 908 is the first step in active processingof incoming broadcast information. Find IC element state 908 searchesincoming data for the occurrence of integrity check tag 402. When anintegrity check tag 402 has been found, execution is passed to theperform integrity check state 910.

[0126]FIG. 10A and B contains flow diagrams illustrating the operationof find IC element state 908 and perform integrity check state 910,respectively. In FIG. 10A the method begins when broadcast informationis received (step 1002). Next, the received data is checked to see if acomplete integrity check tag 402 is present (step 1004). If a completeintegrity check tag 402 is present, the broadcast information is passedto extract integrity element state 910 and the method of FIG. 10B begins(step 1006). If find IC element state 908 determines that a completeintegrity check tag 402 has not been found, it loops back to step 1002and continues to receive data looking for the occurrence of a completeintegrity check tag 402.

[0127]FIG. 10B begins when a complete integrity check tag 402 has beenfound. First, integrity check tag 402 is extracted from broadcastinformation (step 1008). Then the method determines if enough data ispresent to perform an integrity check (step 1010). If enough data ispresent to perform an integrity check, a checksum value is computedacross the data bytes making up window 401 a (step 1012). If there isnot enough data to perform an integrity check, the method reverts backto step 1002 in find IC element state 908 (FIG. 10A). After the checksumis computed in step 1012, it is compared to checksum value 407 containedin integrity check tag 402. If the computed checksum matches checksumvalue 407, integrity check tag 402 is stripped from the data (step1016). If the computed checksum and checksum value 407 do not match,control is passed to step 1002 in find IC element state 908 (FIG. 10A)and more data is received. After integrity check tag 402 is stripped,control is passed to create XML element state 912 (step 1018).

[0128]FIG. 11 contains a flow diagram illustrating the method performedby create XML element state 912. Create XML element state 912 isresponsible for properly parsing received data into an XML structure fordelivery to a destination module that has registered an elementlistener. Create XML element state 912 begins by parsing data receivedfrom perform integrity check state 910 (step 1102). Data received bycreate XML element state 912 is parsed into one or more XML elementstructures that are appropriate for destination modules such as bannerdisplay module 722, service factory module 720, or the like. Next,parsed data is compared to registered element listeners (step 1104). Ifa registered listener is available for the parsed data, it is passed tothe appropriate element listener for forwarding to a destination module(step 1108). If no registered listeners are available, the unmatchedparsed data may be destroyed to free up memory (step 1106). Afterforwarding data to a registered listener or destroying unmatched data,create XML element state 912 parses additional incoming data receivedfrom perform integrity check (IC) state 910 and then repeats steps 1102through 1110.

[0129] Since client 112 is receiving contextually relevant informationfrom emitter 108, it is desirable to design the software operatingwithin client 112 in such a manner as to enable client 112 to easilymodify its behavior based on the current context that it is operatingwithin. One method for easily modifying the behavior of client 112 isthrough the use of plug-in modules. A plug-in module is a small piece ofsoftware running within a larger program. Plugin modules make itpossible to add additional functionality to larger applications withouthaving to modify the core application. In addition, a plug-in moduleperforms necessary communications and data conversions without requiringa user of a device, such as client 112, to know any special programmingor data handling techniques. Methods for developing and integratingplug-in modules are well known in the art, and as such are not describedin detail herein.

[0130] As used in client 112, a plug-in module helps client 112 operatewithin a context by performing processing necessary to extractcontextually relevant information from received data. In addition,plug-ins may be configured based on a user's preferences or behavior tofurther aid client 112 when processing contextual data.

[0131] Returning to the airline example, a plug-in for Logan airport ora particular airline may be available. If used, an airline plug-in mayregister for an XML element associated with a particular flight. Afterregistering for the flight, a client 112 operating in a context relevantto the flight XML element would receive information such as the gatenumber and departure time for a flight associated with the flight XMLelement.

[0132] To obtain maximum utility from a plug-in module, it is beneficialto have it operate in conjunction with other modules operating withinclient 112. Context behavior module 724 is employed for allowing pluginsto easily integrate into and operate in client 112.

[0133] Context behavior module 724 may serve as the interface between aplug-in module and the other software modules operating within client112, for example banner display module 722, communications module 702,service factory module 720, service display module 734, and servicecontainer module 730. As an interface, context behavior module 724 isresponsible for the persistent storage of a plug-in module and thedynamic loading of it when client 112 is operating in a contextassociated with the plug-in. Context behavior module 724 determines thatit is operating in a context associated with a plug-in when it receivesa broadcast information context element for which it has a plug-in.

[0134]FIG. 12 contains a flow diagram illustrating the method performedby context behavior module 724. Broadcast information is monitored forcontextual information (step 1202). When a context element is sensed, itis received by context behavior module 724 (step 1204). Next, contextbehavior module 724 determines if a plug-in exists for the presentcontext (step 1206). If no plug-in is registered, context behaviormodule 724 continues to monitor new incoming data until a contextelement is sensed. If a registered plug-in exists, the appropriateplug-in module is loaded (step 1208). After loading the appropriateplug-in module, it is executed in order to modify the behavior of client112 (step 1210).

[0135] Banner display module 722 is responsible for creating ticker tapelike displays that scroll information across display 139. Banner displaymodule 722 registers with communication module 702 so that it canreceive banner XML elements. In addition, banner display module 722 mayreceive banner XML elements from other modules operating within client112. Information processed and displayed by banner display module 722may be routine information such as the status of an incoming flight, orit may serve as an alert such as when posting information about acancelled flight to a user having a reservation on the respectiveflight.

[0136]FIG. 13 contains a flow diagram illustrating a method performed bybanner display module 722. First, banner display module 722 registerswith communication module 702 so that it can receive banner messages(step 1302). After registering, banner display module 722 may receive aroot banner XML element (step 1304). Upon receiving the banner root XMLelement, banner display module may extract the text to be displayedcontained therein (step 1306). Next, banner display module 722determines if the text is for a routine banner display or for an alertdisplay (step 1308). If the text is for a routine banner display, thetext is formatted for display as such (step 1310). If the text is to bedisplayed as an alert message, banner display module 722 formats thetext into an alert window (step 1312). For an alert message, bannerdisplay module 722 may also communicate with a speaker means, vibratingmeans, or notification means to ensure that a user notices the alertmessage. After formatting the banner display message or the alertwindow, the resulting message or window is sent to service displaymodule 734 (step 1314).

[0137] Service factory module 720, service container module 730, andservice display module 734, all deal with internal representations ofservices within client 112. These modules use service objects torepresent the respective services. Service objects are not the servicesthemselves, but rather they provide client 112 with a convenient way torepresent services, as such service objects act as models for receivedservices. In this capacity, service objects contain informationnecessary to contact a service provider 102 that is providing a servicerepresented by a respective service object. In addition, service objectsare used to execute steps required to perform contact with serviceprovider 102 via communication module 702. Service objects areefficiently managed by associating certain parameters with them.

[0138]FIG. 14 illustrates exemplary service objects created in client112. In addition, FIG. 14 shows states that may be associated with aservice object 1402 in client 112. In particular, FIG. 14 shows serviceobject 1402 having a lifetime state 1404, an alive state, and a deadstate 1416. Alive state 1406 may further include a normal state 1408, adirty state 1410, alert state 1412 and a sick state 1414.

[0139] Lifetime state 1404 is used to constrain the existence of liveservice objects to a finite time. Lifetime state 1404 may take ondifferent values depending on the needs of a given service object. Inaddition, the lifetime associated with a given service object may beextended from a default time by pinging, or querying, lifetime state1404. Upon pinging, lifetime state 1404 will be extended by oneincrement of time as defined by a system designer, service provider 102,or client 112. When the lifetime associated with a service objectexpires, the corresponding service object is destroyed. Since client 112may have limited memory, it is beneficial to minimize the number ofservice objects 1402 being tracked. Lifetime state 1404 is responsiblefor keeping the number of tracked service objects 1402 to a minimum.

[0140] Alive state 1406 is used to identify a service object 1402 thatexists within client 112. Alive state 1406 is further divided intosub-states to better identify the operation of service object 1402within client 112. Normal state 1408 is used to describe a service thatis ready to be activated by a user of client 112. Dirty state 1410 isused to indicate when a user has already interacted with a service. Forexample, a service object in dirty state 1410 may have registered aservice request with communications module 702 and is waiting for aresponse from service provider 102. Alert state 1412 describes a serviceobject having pending information for display to a user of client 112.Sick state 1414 describes the situation where a service object is unableto interact with a user of client 112. For example, sick state 1414 mayindicate that service object 1402 has an alert to display, but a userhas turned off display 139 on client 112 to conserve battery power. Sickstate 1414 may also indicate when client 112 has moved out of a contextin which a service exists and where the service is associated with theservice object. In general, sick state 1414 is used to describe anysituation where service object 1402 cannot accomplish its function.

[0141] Dead state 1416 identifies a service object 1402 that is notalive. For example, a dead service object may be one that has not beeninteracted with by a user or one in which the lifetime has expired.

[0142] Service factory module 720 generates service object 1402 inclient 112 by following a Java factory design pattern. The generation ofservice objects may be stimulated by broadcast information received byclient 112 or by other modules operating therein. Service factory module720 persistently tracks services received by client 112 and it isresponsible for ensuring that information associated with trackingservices is properly stored and that service objects are not recreatedif they have already been handled.

[0143]FIG. 15 contains a flow diagram illustrating a method performed byservice factory module 720. Service factory module 720 receives aservice XML element from communication module 702 (step 1502). Theservice XML element denotes an available service based on a givencontext of client 112. Service factory module 720 determines if theservice object 1402 associated with the service is alive (step 1504). Ifservice object 1402 is alive, service factory module 720 determines ifan icon or executable code is available for utilizing the service (step1506). Service factory module 720 accomplishes this by checking withservice container module 730 to determine if a service object 1402already exists. If service object 1402 already exists, a new serviceobject 1402 is generated from the existing icon or executable code (step1508). Then the icon is passed to the service associated with serviceprovider 102 (step 1510). Next, service object 1402 associated with theservice is passed to service container module 730 (step 1512).

[0144] Returning to step 1506, a new service object is generated if noexecutable code or icon is available (step 1516). The new service objectis then assigned a default icon (step 1518) and stored in persistentmemory (step 1520). Then the service associated with service object 1402is persistently tracked by client 112 (step 1522) and passed to servicecontainer module 730 (step 1512).

[0145] Now returning to step 1504, if no service object 1402 is alive,service factory module 720 creates a new service object 1402 thatreferences the icon or executable (step 1514). Next, service object 1402is stored in persistent memory (step 1520), persistently tracked (step1522), and passed to service container module 730 (step 1512).

[0146] Service container module 730 stores and tracks all serviceobjects 1402 that are alive within client 112. In addition, servicecontainer module 730 kills service objects 1402 when their respectivelifetime has expired. When service objects 1402 are tracked, informationabout them may be stored in a portion of memory referred to as acontainer.

[0147]FIG. 16A, B and C present flow diagrams illustrating the operationof service container module 730. In FIG. 16A, a query referencingservice object 1402 is received from service factory module 720 (step1602). Service container module 730 determines if service object 1402 isalive (step 1604). If service object 1402 is not alive, service factorymodule 720 is notified so that it can create a new service object forthe service (step 1610). If the service object is alive, servicecontainer module 730 updates the lifetime by an increment of time (step1608).

[0148]FIG. 16B illustrates a second method of operation for servicecontainer module 730. Here, service container module 730 iteratesthrough all service objects 1402 and prunes dead ones (step 1614). Whenoperating to prune dead service objects 1402, service container module730 does not have to receive inputs from other modules. A software timermay be established for causing service container module 730 to cyclethrough all service objects 1402.

[0149]FIG. 16C illustrates a third method of operation for servicecontainer module 730. Here, data is received from another module or froman external stimulus (step 1616). The received data is checked to see ifthe associated service object is alive (step 1618). If service object1402 is not alive it is stored in a container managed by servicecontainer module (step 1624). If service object 1402 is alive, thelifetime is extended by an increment of time (step 1620). Afterextending the lifetime by an increment, service container module 730iterates through all service objects 1402 and prunes dead ones (step1622).

[0150] Service display module 734 handles displaying representations oflive service objects to a user of client 112. In addition, servicedisplay module 734 provides a user with a means for interacting withservice objects using a stylus or other input means. Generally it willbe advantageous to divide the display into a number of areas each ofwhich is used to convey particular types of information to a user.

[0151]FIG. 17 illustrates the external features of client 112 in moredetail. In particular, display 139 is shown. Display 139 is shown withan exemplary layout of display areas that may be used for conveying datato, and receiving inputs from, a user of client 112. An alert displayarea 1704 is located near the top of display 139. Alert display area1704 may be used for displaying alert messages to a user. For example,an alert message may be displayed in alert display area 1704 when client112 goes out of a coverage area associated with a given emitter 108 orservice provider 102. Service display area 1706 may be used to presentinformation about active services to a user. For example, servicedisplay area 1706 may be used to display forms to a user after theyactivate a service. Banner display area 1708 may be used to displaybanner messages to a user of client 112. For example, a user at aballpark may receive continuous banner messages containing statisticsabout the game being watched.

[0152]FIG. 18 illustrates an exemplary method that may be performed byservice display module 734. Information is obtained about a service fromservice container module 730 or from banner display module 722 (step1802). Then an icon is displayed to a user in service display area 1706(step 1804). A user interacting with client 112 may enter an input usingdisplay 139. The entered information is then received by service displaymodule (step 1806). Next, the desired service may be activated (step1808). Upon activating the desired service, service display module 734determines if executable code exists for the service object (step 1810).If executable code exists for the service object, the associated file isexecuted (step 1812). If the executable code does not exist, forms maybe created using form XML elements associated with the service anddisplayed to a user (step 1814). Then, a user completes the forms (step1816) and client 112 transfers the data to POP 110 via PDA interface 131(step 1818).

[0153]FIG. 19 contains an exemplary flow diagram showing an overallmethod that may be employed by a user when interacting with serviceprovider 102. Client 112 receives broadcast information via emitter 108(step 1902). Communication module 702 passes the information containedin the received signal to service factory module 720 (step 1904).Service factory module 720 creates a service object 1402 for theavailable service (step 1906). Then, service factory module 720 passesthe newly created service object 1402 to service container module 730(step 1908). Service container module 730 persistently tracks liveservice object 1402 (step 1910). Live service object 1402 is then passedto service display module 734 (step 1912). Service display module 734displays the icon, associated with the service, to a user of client 112(step 1914). A user activates the service using a stylus or other inputmeans (step 1916). If the service is activated for the first time, formsmay open (step 1918), then the user may enter required data (step 1920).The forms are queued for sending by communication module 702 afterreceiving them from service display module 734 (step 1922). Then client112 may connect to POP 110 (step 1924). Next, communication module 702senses the connection and sends queued data (step 1926). After serviceprovider 102 processes data contained in the forms, client 112 receivesdata and/or executable code required to utilize the service (step 1928).After receiving the data and/or executable code client 112 is able toperform context sensitive computing using the service.

[0154] The disclosed invention provides a versatile solution to problemsassociated with providing contextually relevant information to handhelddevices. While preferred embodiments have been presented and discussedin the foregoing detailed description of preferred embodiments,alternative embodiments are possible in view of the teachings containedtherein. Alternative embodiments are possible for service provider 102,network 104, controller 106, emitter 108, POP 110 and client 112.Examples of selected alternative embodiments will be provided below.

[0155] A first alternative embodiment for client 112 may be practiced byemploying a wearable client device. In this embodiment, display 129 maybe comprised of a wearable display, also referred to as a heads-updisplay in the art. A wearable display may be fastenably attached to, orembodied in, a hat or eyeglasses worn by a user; or, the wearabledisplay may be suspended in front of a user's eye using a suspensionmeans fitted over the user's head. In a wearable embodiment, user inputsmay be conveyed to processing hardware and software in client 112 usingvoice commands, sensors attached to a user's fingers, eye movementdetectors, or the like. In addition, processing hardware may be embodiedin or attached to a user's clothing in the wearable embodiment.

[0156] A second alternative embodiment of client 112 may be installed ina vehicle. Such an embodiment may be used to make structures such asparking garages and parking lots more user friendly by providingcontextually relevant information to occupants of a vehicle. Forexample, a parking facility employing the invention may provide a driverwith the location of an empty parking spot, information about thevehicle's location within the parking facility, or information aboutevents taking place in venues in proximity to the parking facility. Inthis embodiment, IR communication interface 130 may be installed in theroof, windshield, bumper, or other suitable location of a vehicle in amanner maximizing reception of emitter signal 142.

[0157] A third alternative embodiment of client 112 may use specializedelectronic circuitry to further minimize size and power consumption. Forexample, functionality of client 112 may be incorporated into a fieldprogrammable gate array (FPGA) or application specific integratedcircuit (ASIC) thus minimizing the size of client 112. For example,FPGAs and ASICs may be used when fabricating a wearable client 112.

[0158] A fourth alternative embodiment of the disclosed invention maypool service providers 102 rather than have them operate separately orin small federations. Pooling service providers has the benefit ofsimplifying bidirectional communications from POP 110 or client 112.Communications are simplified because only one type of message protocolmay be required. Here, software coupling the pool of service providersmay decode received messages and subsequently pass information on to arelevant service provider(s) within the pool.

[0159] In a fifth alternative embodiment controller 106 may beincorporated into one or more service providers 102 rather than beingemployed as a standalone device as depicted in FIG. 1A. Incorporatingcontroller 106 service provider 102 may be desirable when serviceprovider 102 is communicating with a small number of emitters 108 andPOPs 110 having finite coverage areas. An example of this configurationwould be if Logan airport acted as service provider 102 and providedinformation to clients 112 operating only within the airport itself.

[0160] A sixth alternative embodiment may be practiced by incorporatingemitter 108 or POP 110 into other structures utilizing communicationmeans other than optical. For example it may be desirable to incorporateemitter 108 in to a cellular transceiver servicing a microcell such as asporting complex. Here integrating emitter 108 with a cellulartransceiver allows client 112 to receive information via optical signal142 and reply using either optical radiation or RF radiation. Forexample if a sporting complex ran a contest where the first personcalling in with a correct answer to a sports trivia question won aprize, a user could receive contextually relevant information about thecontest via optical signal 142, provide user input 140 using a stylus,and send a reply directly to the appropriate phone number using an RFsignal 143 such as a cellular signal.

[0161] In a seventh alternative embodiment, emitter 108 and POP 110 maygenerate optical signal 142 by modulating an electric light usingtechniques known in the art. Several techniques are known in the art formodulating the drive signal to incandescent or fluorescent lights in amanner that causes the lights to emit infrared signals while stillperforming their normal lighting functions. Using existing lightingfixtures as emitters may help produce cost effective infrastructures fordelivering contextually relevant information to a user of client 112.

[0162] In an eighth alternative embodiment, broadcast signals may notemploy XML elements. In a preferred embodiment, broadcast signalscomprised XML elements to facilitate context sensitive computing withoutrequiring excessive processing in client 112. In embodiments whereclient 112 does not have limited processing power, broadcast signals maytake on essentially any form and may employ essentially any networkprotocol. For example, if client 112 is installed in a vehicle,minimizing power consumption is not normally an issue. Therefore, theinfrastructure may employ protocols and data types that require moreprocessing at client 112 without placing undue strain on it.

[0163] In a ninth alternative embodiment, controller 106, emitter 108 orclient 112 may be designed using object oriented programming techniques.Object oriented programming utilizes software modules, or objects, asthe primary building blocks for software on a respective platform.Modules are designed so that they accept inputs from and provide outputsto other software modules according to a defined format. Modules wishingto communicate with each need only know the input or output format ofthe module they wish to communicate with. Using object orientedprogramming techniques makes it possible for controller 106, emitter108, or client 112 to take on differing levels of functionality based ontheir respective environments. For example, controller 106 may beimplemented with a software module that sends data in XML format andanother module that sends data in an encrypted format. A controller 106so equipped can switch from communicating XML elements to encryptedtraffic by interfacing the appropriate module to link 116. An importantbenefit of using object oriented programming techniques is thatcomponents can modify their operation without requiring hardware changeswhich tend to be expensive and time consuming to implement. As can beseen, using object oriented programming techniques allows the inventionto be easily adapted for addressing a wide range of wirelesscommunication problems.

[0164] As can be seen from the alternative embodiments and preferredembodiments discussed herein, it will be obvious to those skilled in therelevant arts that many additional embodiments and modifications arepossible without departing from the spirit of the invention. Therefore,the present embodiments are to be considered in all respects asillustrative and not restrictive, the scope of the invention beingindicated by the appended claims rather than by the foregoingdescription, and all changes within the meaning and range of equivalencyof the claims are therefore intended to be embraced therein.

what is claimed is:
 1. A method for distributing an advertisementassociated with a service to a client device, said method comprising thesteps of: propagating said advertisement from a transmitter to saidclient device, said propagated advertisement forming an advertisingsignal containing advertising information; receiving said advertisingsignal at said client device; decoding said advertising signal toextract said advertising information; and displaying said advertisinginformation to a user of said client device.
 2. The method of claim 1wherein said advertising information comprises: an XML elementcomprising: service information enabling said user of said client deviceto make a decision about said service; data entry information informingsaid user about utilizing said service; and contact informationcontaining instructions for enabling said client device to communicatewith said service.
 3. The method of claim 2 further comprising the stepof selecting said service based on said advertising information.
 4. Themethod of claim 3 further comprising the step of constructing a userinterface for allowing said user to communicate with said client device.5. The method of claim 4 further comprising the step of receiving userinputs communicatively associated with said advertising information. 6.The method of claim 5 further comprising the step of formatting saiduser inputs and a portion of said advertising information into a userreply, said user reply for making said user inputs available to saidservice.
 7. The method of claim 6 wherein said user reply is received atsaid transmitter.
 8. The method of claim 7 wherein said user reply isreceived as a wireless signal from said client device.
 9. The method ofclaim 7 wherein said user reply is received at said transmitter using acommunication interface providing electromechanical contact between saidclient device and said transmitter.
 10. The method of claim 9 furthercomprising the step of receiving a service response from saidtransmitter, said service response including at least one memberselected from the group consisting of a graphical representation of saidservice for display on said client device, executable code for allowingsaid client device to interact with said service, and text for displayon said client device.
 11. The method of claim 6 wherein said user replyis received at a point-of-presence (POP).
 12. The method of claim 11wherein said user reply is received over a personal digital assistant(PDA) interface providing electromechanical contact between said clientdevice and said POP.
 13. The method of claim 12 further comprising thestep of receiving a service response from said POP, said serviceresponse including at least one member selected from the groupconsisting of a graphical representation of said service for display onsaid client device, executable code for allowing said client device tointeract with said service, and text for display on said client device.14. The method of claim 1 wherein said advertisement is propagated as anoptical signal through air.
 15. The method of claim 14 wherein saidoptical signal has a wavelength in the range of substantially 850nanometers to 1250 nanometers.
 16. The method of claim 15 wherein saidtransmitter receives said advertisement over an Internet.
 17. The methodof claim 15 wherein said transmitter receives said advertisement over afiber optic network.
 18. The method of claim 1 wherein said clientdevice is a personal digital assistant (PDA).
 19. A method for conveyingan advertisement from a transmitter having a link layer, said methodcomprising the steps of: receiving said advertisement from a service;formatting said advertisement for transmission to a client deviceoperating within a context associated with said transmitter; andconveying said advertisement to said client device over a communicationmedium.
 20. The method of claim 19 wherein said advertisement iscomprised of an XML element.
 21. The method of claim 20 wherein saidadvertisement includes: service information enabling a user of saidclient device to make a decision about said service; data entryinformation informing said user about utilizing said service; andcontact information containing instructions for enabling said clientdevice to communicate with said service.
 22. The method of claim 19wherein said advertisement is conveyed from said transmitter as adiffuse infrared signal.
 23. The method of claim 22 wherein said diffuseinfrared signal has a wavelength in the range of substantially 850nanometers to 1250 nanometers.
 24. The method of claim 19 wherein saidclient device includes a client device physical layer and a clientdevice link layer compatible with said link layer in said transmitter.25. A method for receiving an advertisement from a transmitter having anemitter link layer associated therewith, said method comprising thesteps of: receiving said advertisement at a communication interface;decoding said advertisement to extract information contained therein;processing said information; and displaying said information to a user.26. The method of claim 25 wherein said emitter link layer is compatiblewith a client device link layer associatively coupled to saidcommunication interface.
 27. The method of claim 25 wherein saidinformation is displayed using a plug-in cooperatively associated withsaid advertisement.
 28. The method of claim 27 wherein said plug-infurther includes information about a preference of said user.
 29. Amethod of utilizing executable code in a transmitter for providing anadvertisement to a client device operating within a coverage areaassociated with said transmitter, said method comprising the steps of:receiving said advertisement from a service provider, said advertisementfurther being associated with a service offered by said serviceprovider; formatting said advertisement for transmission to said clientdevice; and conveying said advertisement from said transmitter to saidclient device over a communication medium.
 30. The method of claim 29wherein said advertisement is comprised of an XML element.
 31. Themethod of claim 30 wherein said advertisement further comprises: serviceinformation enabling a user of said client device to make a decisionabout said service provider, said decision being based on said serviceinformation; data entry information informing said user about utilizinga service associated with said service provider; and contact informationcontaining instructions for enabling said client device to communicatewith said service provider.
 32. The method of claim 29 wherein saidadvertisement is conveyed from said transmitter as a diffuse infraredsignal.
 33. The method of claim 32 wherein said diffuse infrared signalhas a wavelength in the range of substantially 850 nanometers to 1250nanometers.
 34. The method of claim 33 wherein said diffuse infraredsignal is generated by modulating an electric light.
 35. A method ofutilizing executable code in a client device receiving an advertisementfrom a transmitter, said method comprising the steps of: receiving saidadvertisement from an infrared communication signal conveyed from saidtransmitter and arriving at a communication interface associated withsaid client device, said advertisement containing at least a portion ofa service offered by a service provider; decoding said advertisement toextract information contained therein; processing said information; anddisplaying said information to a user of said client device;
 36. Themethod of claim 35 wherein said advertisement is comprised of an XMLelement.
 37. The method of claim 36 wherein said advertisement furthercomprises: service information enabling said user to make a decisionabout said service, said decision based on said service information;data entry information informing said user about utilizing said service;and contact information containing instructions enabling said clientdevice to communicate with said service provider.
 38. The method ofclaim 37 wherein said transmitter includes an emitter link layer. 39.The method of claim 38 wherein said client includes a client device linklayer.
 40. The method of claim 39 wherein said emitter link layer iscompatible with said client device link layer.
 41. The method of claim40 wherein said information about said service is displayed to said userif said client device is running a plug-in cooperatively associated withsaid service.
 42. The method of claim 41 wherein said plug-in furthercomprises information about a preference of said user.